Page history of API 서버 개발 중의 고민

외주로 위치정보를 많이 쓰는 앱의 API 서버를 제작 중이다. 이와 관련해서 요즘 하고 있는 설계 고민들을 적어본다.

데이터베이스 선택

위치정보를 많이 쓴다면 2차원 인덱스를 통해 KNN Query 등의 위치정보 관련 쿼리를 쉽게 할 수 있는 MongoDB가 편하다. 그러니까 MongoDB 하나만 쓰고 RDBMS는 쓰지 말까? 아니면 그냥 Django 모델은 그대로 쓰고, MongoDB는 위치정보 인덱스로만 쓸까? Django 모델의 편리함을 그냥 버리긴 아깝다. 아니면 OpenGIS를 지원하는 PostgreSQL을 쓰면 다 해결되려나? 

고민 끝에 일단 MongoDB를 전면적으로 쓰기로 결정했다. 이미 채팅촌에서 써본 경험이 있었는데 괜찮았고, PostGIS는 사용하기 그리 편하지 않았다. MongoDB를 위치정보 인덱스로만 쓰고 Django 모델을 주로 쓰는 접근법도 해봤는데, 나름 괜찮긴 하지만 조금 더 MongoDB를 깊이 써보고 싶었다.

모델 레이어

MongoDB를 쓰기로 했으니 파이썬에서 어떻게 사용할지를 결정해야 했다. 크게 방법은 세 가지. pymongo를 그대로 쓰는 것, MongoKit, MongoEngine. 셋 다 나쁜 방법은 아니지만, 아무래도 MVC에서 모델 중심으로 가려면 pymongo를 그대로 쓰긴 좀 그렇고 뭔가 wrapping을 하긴 해야 한다. MongoEngine은 저번에 써봤는데, Django model을 닮은 게 그다지 맘에 들진 않았다. MongoDB로 계속 개발을 하려면 아무래도 MongoDB의 쿼리 문법에 익숙해져야 하므로 그걸 그대로 쓰는 게 유익하다. MongoEngine이 Django랑 억지로나마 연동이 되긴 하지만, Admin 연동이 제대로 안되는 이상 별로 큰 이득도 아니다. 그래서 MongoEngine은 시도도 안해보고 MongoKit으로 넘어왔다. 근데 MongoKit도 생각보다 불편하다. 가장 불편한 건 collection을 wrapping해서 관리해주지 않고 들고 다녀야 한다는 것이다. MongoKit에서의 document 생성은 다음처럼 database와 collection을 가져온 다음 거기서 모델 객체를 생성해야 한다.

connection.database.collection.MyDocument()

왜 MyDocument()를 바로 쓰는 걸 지원하지 않는지 이해할 수 없다. database와 collection을 미리 지정해두면 이 둘은 생략할 수 있지만, 그래도 connection에 붙여서 써야 한다. 쿼리도 마찬가지다. 별 거 아닐지 모르지만 그냥 이게 맘에 안 들어서 버리기로 했다. 그래서 그냥 예전에 내가 간단하게 만들어 둔 MongoDB model wrapper를 계속 쓰기로 했다. 이름도 붙였다. MongoDB Model을 줄여서 momo.

스키마 문서화

외주다보니 스키마 문서화가 필요하다. Django 모델로 작성했으면 그냥 django-extensions의 graph_models 써서 다이어그램 넘겨버리면 그만이겠지만, momo는 그런 거 없다. 그리고 MongoDB는 schemaless가 기본이다보니 스키마를 정의하는 일이 부가 작업이 된다. 여기서 고민에 빠졌다. 따로 코드로 스키마를 정의할 필요가 없으니 그냥 수동으로 다이어그램만 그려서 관리할까, 아니면 그래도 스키마가 코드에 정의되는 게 명시성도 좋고 나중에 validation 붙이기도 좋으니 코드에 정의하고 다이어그램은 자동으로 뽑아낼까. 

별도 문서화보다는 아무래도 코드에 정의를 하고 싶다. 코드에 정의를 하면 나도 개발을 하면서 계속 참조할 수 있어 이득을 얻기 때문이다. 사실 클라이언트에서 꼭 다이어그램까지 원하는 것은 아니기 때문에 스키마 정의한 문법을 그대로 보내줘도 될 것 같긴 하다. 다만 조금 세련된 문법이면서, 나중에 programmable하게 처리할 수 있는 구조이기만 하면 될 듯.

스키마를 코드에서 정의한다면 MongoKit을 베낄까, MongoEngine을 베낄까도 고민이다. MongoKit이 간결하고 시각적이지만, MongoEngine은 여러 가지 속성을 줄 수 있어서 확장성이 좋다. 문법 정의할 때 파이썬이 인터프리터 언어라는 점도 은근히 귀찮다. 클래스 정의할 때 자신을 참조하게 만들 수가 없기 때문이다. method 안에서는 참조할 수 있지만 클래스 레벨로 정의할 때는 참조할 수가 없어서 Django 모델도 문자열이나 'Self' 같은 문법을 쓴다. 아직 이 부분은 고민 중.

REST API 프레임워크

일단 django를 쓰긴 할 텐데, REST API는 뭘로 만들까? 이전까지는 그냥 내가 만든 djangox-route를 써서 라우팅만 처리하고, JSONResponse 같은 걸 또 붙여서 대충 썼다. PUT, DELETE 따윈 지원하지 않지만 내 프로젝트라면 아마 또 그렇게 할 듯. 하지만 외주다보니 좀더 제대로(?) 만들어야 하고, 또 좀더 널리 알려진 프레임워크를 쓰는 게 좋을 듯 하다. 그래서 django-rest-framework와 tastypie를 비교하기 시작했다.

둘다 예제가 너무 Django model 연동 중심으로 되어 있다. 하지만 난 Django 모델을 안 쓰기로 한지라, 별로 도움이 안된다. 모델을 바꿔 끼우려고 해보니 tastypie는 상속해야 하는 메서드들이 좀 이상하다. get_object_list와 obj_get_list라는 어이 없는 네이밍을 해놨다. 확장하려고 문서를 찾아보니 문서도 좀 부실하다. 그래서 잠깐 django-rest-framework 문서를 더 보는데, 일단 문서가 좀더 풍부하고, browsable api가 있어서 이게 더 편할 것 같았다. View와 Serializer를 API마다 세트로 작성해야하는 것처럼 보여서 조금 꺼려지긴 했지만, 아마도 Serializer는 어떻게든 하나로 할 수 있는 방법이 있겠지. 그래서 일단 django-rest-framework로 왔다. 생각보다 쉽게 연동이 되서 Browserable API에서 JSON으로 POST하고 조회하고 하는 건 잘 된다. 일단 API 작성까지는 이게 괜찮은 것 같다.

그런데 또 하나 중요한 건 API 문서화다. 요즘 REST API는 executable documentation이 대세가 되어가고 있고, django-rest-framework의 Browsable API도 그걸 지원한다. 그런데, 이게 좀 제한적이다. 문서화 기능도 적고, list에 GET 요청을 할 때 파라미터를 줄 수 있는 UI는 없는 것 같아보인다. POST야 그냥 JSON으로만 해도 되서 별 상관은 없지만 필터링 파라미터는 필요한데 아직 어떻게 하는지 모르겠다.

그래서 documenting-your-api라는 문서를 봤더니 자체 Browsable API의 문서화보다 오히려 django-rest-swagger를 추천한다. 이건 swagger integration인데, 이것도 생각보다 쉽게 붙었다. 그런데, 클래스 레벨의 docstring만 파라미터 인식을 하고, 메서드 레벨로는 안되는 것 같다. 한글도 문제가 있는지 에러를 낸다. 하지만, 일단 UI 자체에는 필요한 기능이 다 담겨 있는 것 같다. 일단은 이걸로 좀더 파볼 듯. 처음 원했던 것처럼 손 안대고 코 푸는 건 아직 안되는 것 같다.

블로그 / 소프트웨어 개발